ssl: first pass limit when allocating buffer for certificates #7131
Conversation
With this check, on the first packet of a certificate presenting a length of 16Mbytes, we only allocate up to 65Kb When we get to the point where need more than 65Kb, we realloc to the true size. With this check, it makes it more expensive for an attacket to use this allocation as a way to trigger ressource exhaustion...
Codecov Report
@@ Coverage Diff @@
## master #7131 +/- ##
==========================================
+ Coverage 78.06% 78.09% +0.02%
==========================================
Files 628 628
Lines 185266 185271 +5
==========================================
+ Hits 144635 144684 +49
+ Misses 40631 40587 -44
Flags with carried forward coverage won't be shown. Click here to find out more. |
| @@ -1431,6 +1431,10 @@ static int EnsureRecordSpace(SSLStateConnp *curr_connp, const uint8_t * const in | |||
| SCLogDebug("cert_len unknown still, create small buffer to start"); | |||
| certs_len = 256; | |||
| } | |||
| // Limit in a first time allocation for very large certificates | |||
| if (certs_len > 0x10000 && certs_len > curr_connp->trec_pos + input_len) { | |||
There was a problem hiding this comment.
should we first check if current input will set the limited value?
Also please use a macro with a clear name, a decimal value and a comment to explain the default
There was a problem hiding this comment.
should we first check if current input will set the limited value?
I am not sure I understand your question.
This is a first check that current input will set the limited value...
That is if not certs_len > curr_connp->trec_pos + input_len that means that the current input will cross the 65k boundary, and thus, we do not limit ourselves
|
Information: QA ran without warnings. Pipeline 6537 |
|
Replaced by #7139 |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5188
Describe changes:
Feedback welcome here